Summary

Four correctness fixes to the Stellar→TFChain deposit/mint path (pkg/stellar/stellar.go). These were identified while decomposing the larger batching/idempotency work (#1079) into independently-shippable pieces. They are bridge-only, no runtime upgrade, and independent of the idempotency/batching changes.

Two of the four are fund-safety issues that exist on development today.

Changes

1. Credited-effect asset check: && → || (fund-safety)

processTransaction skipped an account_credited effect only when both the asset code and the issuer were wrong:

if creditedEffect.Code != asset[0] && creditedEffect.Issuer != asset[1] { continue }

So a credit with the right code but a forged/wrong issuer (or vice-versa) passed the gate. This is the only asset gate before the mint amount is summed. Fixed to require both to match (consistent with the ||-form check already used elsewhere in the file).

2. Per-op loop: return nil, nil → continue (fund-safety)

The operation loop returned from the entire function on the first non-payment operation, silently discarding any legitimate payment ops later in the same transaction → lost deposits / missing mints. Now skips non-payment ops individually.

3. Operation-level asset validation (defense-in-depth)

The effect check gates entry to the loop, but each payment amount was summed without re-checking its asset. Added a per-payment Code/Issuer guard so a non-TFT payment to the bridge in the same transaction can't be minted as TFT; non-TFT payments are skipped and logged as an alert.

4. StatBridgeAccount: || → &&

Balance lookup matched on code or issuer, so it could return an unrelated asset's balance. Now matches on both. (Observability only — not fund-moving.)

Logic reasoning & regression-vector verification

• Do legitimate TFT deposits still mint? Yes. A real TFT deposit has the canonical (code, issuer), so it passes both the || effect gate and the new op-level guard unchanged.
• Can fix dockerize node and add it to graphql setup #1 now wrongly reject good deposits? No — rejection only happens when code or issuer doesn't match the configured TFT asset, which a genuine TFT deposit never does.
• Can fix document architecture and reason #2 now mint something it shouldn't? No — the op loop still requires op.GetType() == "payment", To == bridge && From != bridge, and (new) the TFT asset match. continue only lets later ops be evaluated under those same guards instead of aborting the tx.
• Native XLM / other assets: native and non-TFT payments have a non-matching Code/Issuer → skipped+logged by fix investigate test release #3. No mint.
• Fix Feat/offchain worker #4: native balance (empty code/issuer) and foreign assets no longer match; only the exact TFT trustline balance is returned. Returns the existing "no trustline" error if absent (unchanged behavior).

Testing

• go build ./... — OK
• go vet ./pkg/stellar/... — OK
• gofmt -l — clean

The bridge has no Go unit harness for processTransaction; changes are surgical and reasoned above. (A decode/mint unit test is a worthwhile follow-up.)

🤖 Generated with Claude Code